Blogs

My last post was about putting guidelines around the fine-tuning of recognition accuracy.  This post, similarly, is about the risks of being overwhelmed by product features and configuration.

It is ironic that when we have conversations about technology, much of our time is spent discussing how to configure a solution, but the true value is its use.  Be it governance and best practices, or nitty gritty things such as setting a document scanner to 300 DPI or making sure the duel-stream checkbox is checked.  We are feature obsessed.  It’s not wrong to put so much focus on setting up technology correctly, but it does make us lose sight of what the technology was actually created for, to be used.

How enterprise software is consumed is, in my mind, is too often ignored.  It is after all the ultimate goal. I assume expensive software is not purchased with the intent of tinkering with it forever.  So what can we do to bring the use cases back into focus?

First know what a use case is.  A use case is a solution agnostic statement about how something should operate in simple layman’s terms.  A use case for blog posting could be “in a browser window type the text of the blog, when complete posts it for others to see”.  Use cases are activities, not features. 

Part of what I try to get companies to do is to focus on the use cases.  Most organizations start with the problem, and go instantly into advertised solutions to that problem.  Rather organizations may consider starting with a problem, and next envision an ideal solution to that problem.  Staying technology agnostic, an organization should be able to describe how they want technology to play a role in the problem they are trying to solve.  I’m not talking about pie in the sky dreams, but a reasonable expectation.

Step one problem, step two envisioned solution, now step three the users.  Considering how the solution will be used is critical to adoption, and long term success.  It does not matter if you have the greatest technology in the world, if users are unwilling or unable to operate the system you will never hit any sort of actualization.  Part of step three is understanding the capabilities of your users, as well as how they work today.  Often with new technology comes over complicated user interfaces. Rather the growing trend is for UI to match use cases not features.  Meaning you select an activity that automatically activates features. A good example of the difference is my remote control.  When I really want to watch a Blu-Ray, instead of turning on the TV, then the Blu-Ray player, then the receiver, which are the features, I hit “Watch Blu-Ray”, the activity, and the remote does the rest.  As a user all I care about is getting to the movie menu, not about the features it takes to get there. This trend is going to continue to grow, and how knowledge workers are accepting technology to be.  I would argue overcomplicated solutions are immature solutions.

We talk all day about the features and capabilities of enterprise software, but don’t often talk about their applied use.  The impressiveness of technology alone cannot break past the wall of user adoption and prolonged operation. Framing the technology discovery by incorporating these three additional steps will bring more insight into the picture, and foster better decision making and implementation.